1. Field of the Invention
The present invention relates to a network management system including a plurality of devices, such as image processing apparatuses, and a management apparatus connected to the devices via a network, and a network management method.
2. Description of the Related Art
As a protocol for managing devices on a network, there has bee proposed SNMPv1 (Simple Network Management Protocol, SNMP version 1).
According to the SNMPv1 network management technique, in a network management system, there are provided at least one network management station (NMS) and a plurality of managed nodes each including an agent. In this case, a network management protocol is necessitated which is used when the network management station and the agents exchange management information with each other. A user can communicate with agent software on the managed nodes using network management software on the NMS, to thereby acquire or change data on the network or change.
The term “agent” is intended to mean software that operates as a background process for each target apparatus. When the user requests management data of the apparatus on the network, the management software puts object identification information in a management packet, and sends the same to a target agent. The agent interprets the object identification information, and takes out data associated with the object identification information, and puts the data in a packet to send it to the user. It should be noted that to take out data, an associated process is sometimes called.
Further, the agent holds data concerning the state of its own in the form of a database. This database is called an MIB (Management Information Base). The MIB has a tree data structure in which all the nodes are uniquely numbered. The identifiers of the nodes are called object identifiers.
The structure of MIB is called an SMI (Structure of Management Information). This structure is defined in RFC1155 “Structure and Identification of Management Information for TCP/IP-based Internets”.
Next, a brief description will be given of SNMPv1. A client PC (hereinafter referred to as “the manager”), on which the network management software is in operation, and a managed network device (hereinafter referred to as “the agent”), on which an SNMPv1 agent is in operation, communicate with each other using SNMPv1 (see FIG. 1). There are four kinds of SNMPv1 commands, which are called GetRequest, GetNextRequest, SetRequest, and TRAP, respectively.
GetRequest and GetNextRequest are sent from the manager to the agent so as to acquire the value of the MIB object of the agent. The agent, which has received these commands, notifies the manager of the value of the MIB.
SetRequest is sent from the manager to the agent when the manager sets a MIB object value to the agent. The agent, which has received this command, notifies the manager of the result of the setting of the MIB object value.
TRAP is sent from the agent to the manager so as to notify the manager of a change in a state of its own.
The SNMPv1 agent operates on a network board connected to a PC, a printer, and/or the like, and the network management software, which serves as an SNMPv1 manager, operates on the PC. Examples of the network management software include various types from a stand alone type, which operates on the PC, to a server type which can be accessed from a WEB browser.
SNMPv1 is widely used and is mounted on various network devices, since it is simple in specification and easy to mount.
However, SNMPv1 suffers from the problem that it has a low security function, and hence SNMPv3 is standardized which is capable of protecting SNMP packets from wiretapping, impersonation, alteration, and resending, on the network (see FIG. 2).
In SNMPv3, the SNMP manager and the SNMP agent of SNMPv1 are generically referred to as SNMP entities. The SNMP entity is comprised of an SNMP engine and an SNMP application (see FIG. 3).
The SNMP engine is identified by an SNMP engine ID within the same management domain, and provides services for authentication, transmission and reception of encrypted messages, and control of access to managed objects.
Referring to FIG. 3, the SNMP engine is comprised of four component elements, i.e. a dispatcher, a message processing subsystem, a security subsystem, and an access control subsystem. The dispatcher performs transmission and reception of SNMP messages to and from the network. The message processing subsystem analyzes the SNMP messages (PDU). The security subsystem performs the authentication and encryption processing of the SNMP messages. The access control subsystem performs restriction on access to the MIB object.
Differently from community name-based authentication in SNMPv1, the security subsystem carries out the authentication and encryption on a user basis. Further, SNMPv3 supports privacy functions (encryption and decryption), which are not supported by SNMPv1. The user authentication and the privacy functions can be set on a user-by-user basis. A method of supporting HMAC-MD5-96 and NMAC-SHA-96 as user authentication protocols, and CBC-DES as a privacy protocol is described in RFC 3414.
The SNMP application is comprised of five sections: a command transmitting section, a command response section, a notification transmitting section, a notification receiving section, and a proxy section. The command response section responds to requests for acquiring and setting the MIB project. The notification transmitting section transmits notifications, such as TRAP. The proxy section transfers SNMP messages.
Commands used in SNMPv3 include GetBulkRequest and InformRequest in addition to the commands GetRequest, GetNextRequest, SetRequest, and TRAP in the case of SNMPv1.
GetBulkRequest is a command by which the entity acquires the value of the MIB object from another entity. This is a command obtained by improving the access efficiency of GetNextRequest, and makes it possible to acquire a designated number of instances from the instances of designated objects.
As distinct from the event notification of TRAP which is a one-way notification, InformRequest is an event notification command requiring response confirmation.
SNMPv3 is defined in detail in RFCs, including RFC3411, RFC3412, RFC3413, RFC3414, RFC3415, and RFC3416 (RFC3411: “An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks” http://www.faqs.org/rfcs/rfc3411.html; RFC3412: “Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)” http://www.faqs.org/rfcs/rfc3412.html, RFC3413 “Simple Network Management Protocol (SNMP) Applications” http://www.faqs.org/rfcs/rfc3413.html; RFC3414 “User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (USM) (SNMPv3)” http://www.faqs.org/rfcs/rfc3414.html; RFC3415 “View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)” http://www.faqs.org/rfcs/rfc3415.html; RFC3416 “Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)” http://www.faqs.org/rfcs/rfc3416.html)
Next, a description will be given of device search. To manage network devices, first, it is necessary to search for devices connected to a network. To search for the devices connected to the network, device search is executed by broadcasting SNMPv1. FIG. 4 is a view showing the outline of how device search is carried out.
As shown in FIG. 4, a server 101, on which an integrated device management application is in operation, transmits broadcast packets of SNMPv1, and finds a device 102 and a device 103, on which SNMPv1 is in operation, by the search to thereby acquire and hold device information on the device 102 and the device 103. An IT manager accesses the integrated device management application from a PC 100 via a browser, and displays the results of the device search, as shown in FIG. 5. A sequence of the device search is performed in two phases, as shown in FIG. 6.
A device search section in the integrated device management application carries out SNMPv1 broadcast in Phase 1. The devices 102 and 103 respond to the SNMPv1 request. Device information necessary for using the functions of the integrated device management application is additionally acquired from the devices found by the search, in Phase 2 (see Japanese Laid-Open Patent Publication (Kokai) No. 2000-339259 and Japanese Laid-Open Patent Publication (Kokai) No. 2001-282655). Further, in the case of SNMPv3 devices, only IP addresses are displayed as a list, as shown in FIG. 7.
However, when only IP addresses are displayed as a list of device information, it is difficult to identify devices, which considerably degrades operability of the device management application used by the IT manager.
Further, there has also been proposed a device search method which acquires only basic information on devices by a third protocol (e.g. SLP (Service Location Protocol)) other than SNMPv1 and SNMPv3. The reason for acquiring only basic information on devices is to ensure security.
However, the device search method of acquiring only basic device information by the third protocol is limited in the acquired device information. This places restrictions on the functions of the device management application, such as the function of displaying a list of device information, and a device filter function, which considerably degrades the operability of the device management application used by the IT manager.